Fix resource leaks in Application teardown (WebGL context + renderer event listeners) - #1582

Three related leaks in Application teardown, found while chasing intermittent CI test failures. The symptom was always the same and always misleading: renderTargetPool.spec.js and texturecache-batcher-reset.spec.js failing with Hook timed out in 90000ms in a beforeAll calling getWebGLRenderer — never an assertion failure, 5840 other tests passing, and a re-run of the identical commit often going green.

Those two specs were only ever the victims. vitest.config.ts:28-31 already named the mechanism:

each extra spec file that calls video.init creates another WebGL context in the one shared browser session, and past the browser's context cap a later beforeAll stalls

hookTimeout: 90000 was the mitigation. These are the causes.

1. destroy() never released the GL context

WebGLRenderer.destroy() deleted every GL object it owned and Application.destroy() removed the canvas from the DOM — but neither handed back the context. A canvas keeps its context until the canvas is garbage-collected, which is non-deterministic and routinely delayed. Chromium keeps ~16 live and force-loses the oldest past that.

Now released via WEBGL_lose_context. The hint had been sitting commented out in that same file (webgl_renderer.js:295-296). destroy() is already terminal — init() refuses to run again — so losing the context forecloses nothing.

This affects shipped games, not just CI: any SPA that unmounts a game view leaks a context per teardown. The examples gallery does exactly that on every navigation.

2. Renderers never unregistered their global event listeners

WebGLRenderer subscribed to GAME_RESET, ONCONTEXT_RESTORED, CANVAS_ONRESIZE; CanvasRenderer to GAME_RESET. All four were inline anonymous arrows — which cannot be passed to off(), so nothing could ever unregister them. CanvasRenderer had no destroy() at all, inheriting the base no-op.

This is why fix 1 alone was not enough: each handler closes over the renderer, so the subscription pinned the renderer, its batchers and its GPU objects against garbage collection. The context was freed; the JS graph stayed reachable from the event bus.

Handlers are now per-instance fields and destroy() unregisters each — matching what WebGPU already did correctly (webgpu_renderer.js:3268-3269). That asymmetry showed up twice in this work: the newer backend was the careful one both times.

3. Specs leaked 24 GL-capable Applications

An audit parsing the renderer: argument at each new Application( call site — not grepping filenames, since camera3d_integration has 19 Applications but deliberately uses CANVAS — found 24 GL-capable Applications created in specs that never call destroy(). Against a ~16 cap, that is the pile-up.

Two kinds, two fixes:

• Suites that never needed GL — bezier, linedash, timer — pinned to video.CANVAS. An unspecified renderer resolves to AUTO, so these silently held a context all session.
• Reset-only Applications: a fresh app built inside afterAll purely to restore global defaults for later spec files. Eight of these took a context under AUTO and were never destroyed. They do not render, so they are now CANVAS.

Also adds afterAll teardown to the three converted suites — a Canvas Application still leaves a canvas, listeners and timers behind, so it should be destroyed whichever backend it uses.

Tests

tests/application_lifecycle.spec.js (new) and an updated contract in webgl_vao_teardown.spec.js, whose old assertion (getError() === NO_ERROR after destroy) a deliberately-lost context cannot satisfy. It now asserts isContextLost() — verified to fail with the fix reverted.

Two things deliberately not shipped, both recorded in-file so they are not re-derived:

• A "create/destroy N applications past the context cap" test — written and deleted, because it passed identically with and without the fix. On a real GPU the cap is never reached at any N a unit test can afford. A test that cannot fail is worse than none.
• A behavioural "destroy, then emit(GAME_RESET), assert no reaction" test — emit reaches every listener in the shared browser session including ones left by other spec files, and throws partway through; a try/catch would pass without reaching the handler under test. Spying on event.off instead is impossible in vitest browser mode (ESM namespaces are not configurable).

So the lifecycle spec asserts the structural property that made the bug possible: handlers must be retrievable per-instance references. That is necessary but not sufficient — it would not catch a destroy() that simply forgot to call off(). Stated plainly in the spec rather than implying more coverage than exists.

Known remaining, not fixed here

World (GAME_RESET) and Container (CANVAS_ONRESIZE) have the same unpaired-subscription shape. Container is the significant one — every container in the scene graph takes a listener, so a level reload accumulates them. Left out to keep this reviewable; worth its own change.

Whether this fully stops the CI timeouts is not proven — it removes the accumulation mechanism, and the leak counts are measured, but I could not reproduce the timeout locally on a machine with a real GPU.

Gates

🤖 Generated with Claude Code

https://claude.ai/code/session_01QVjYzf76AEU3wJk766JAQi